1. Field of the Invention
The present invention relates to the field of speech technologies, and, more particularly, to performing a safety analysis for user-defined voice commands to ensure that the voice commands do not cause speech recognition ambiguities with a set of preexisting voice commands.
2. Description of the Related Art
Voice-enabled systems often permit users to define a set of actions which are automatically executed in the future responsive to a user-defined voice command The set of actions can be referred to as an abstraction. Many different types of abstractions exist including scripts, macros, and collections. A script can be a time dependent abstraction. A macro can be a sequence of ordered steps or actions, where the beginning of one step is contingent upon a completion of an earlier step. A collection can include a set of asynchronous actions. The user-defined voice command that triggers an execution of an abstraction can have a logical relationship to the set of actions to be performed. For example, a user can define an abstraction “Wake-Up” consisting of a series of steps where a computing system (1) sounds an alarm, (2) starts to brew a cup of coffee, (3) starts a shower, and (4) prints a dally calendar for the user.
Voice-enabled systems often allow a user to invoke an abstraction in more than one way. One way is to preface an abstraction name with a keyword, such as “Playback” or “Execute.” For example, the abstraction above can be invoked with the voice command “Playback Wake-Up”. Another, and more natural, way to invoke an abstraction is to issue the abstraction name by itself, without a trigger word. So the exemplary abstraction can be invoked with the voice command “Wake-Up.”
Few conventional voice-enabled systems allow users to directly invoke user-defined voice commands due to potential naming conflicts with other voice commands accepted by the system. Instead, most voice-enabled systems require a keyword be provided before a user-defined command. This permits the system to enter a special recognition mode, where the system assumes that a user-defined command follows the keyword. Implementers of conventional voice-enabled systems have mistakenly assumed that use of a keyword alleviates misrecognition problems associated with user-defined voice commands, which is not the case. Further, required use of a keyword results in a less intuitive interface than would result if systems permitted user-defined commands to be directly invoked.
To illustrate the problem, a vehicle can include a voice-enabled system capable of recognizing voice commands and taking action in response to these commands. A system command of “Brake” can result in the brakes of a vehicle being applied to stop the vehicle. A passenger can define a command “Breakfast” that is associated with a series of user-defined actions, such as (1) rolling up the windows, (2) turning on the air conditioner, and (3) playing the radio softly, which together place the vehicle in a passenger-preferred state for the passenger to eat breakfast in the vehicle.
If the vehicle were to allow direct execution of user-defined commands, the vehicle system can easily confuse the command “Breakfast” with “Brake” causing the vehicle to abruptly stop when a command giver desired the windows to roll up, the air conditioner to be turned on, and the radio to be played softly. This problem still is present when a keyword is required before a user command.
For example, a passenger can inadvertently utter “Breakfast” without the keyword, which will most likely be misinterpreted as the command “Brake,” which may have unfortunate consequences. Even if the passenger correctly utters the keyword followed by the abstraction name (“Playback Breakfast”), the system can misrecognize or fail to recognize the keyword, which can result in the system misinterpreting the abstraction command as “Brake.” Recognition ambiguity issues resulting from systems permitting users to define voice commands have not been addressed within conventional voice-enabled systems.